To connect an Internet user's computer to a server hosting a webpage, a web server, an Internet Protocol (IP) address of the web server is typically required. Yet, users and web browsers typically only have access to a domain name such as “abc.example.com”. To access the webpage, a web browser submits a domain name system (DNS) query to the DNS. A DNS query typically includes a domain name and the DNS either returns an IP address of the server hosting the URL or an error.
The DNS includes authoritative DNS servers that are servers responsible for translating domain names into IP addresses. Authoritative DNS servers can also be arranged in hierarchies where each level of authoritative DNS server is responsible for a level of the domain. For a given level, there are also master and slave authoritative servers and clusters of authoritative DNS servers that each maintain synched records of domain names and IP addresses. By distributing DNS records over multiple servers, loads on an authoritative DNS server can be reduced.
Yet, DNS queries would still place insurmountable loads on authoritative DNS servers, so caching on alternative servers is used to reduce the number of queries that reach authoritative DNS servers. These alternative servers are called recursive DNS servers, name servers, DNS cache servers, caching name servers, or DNS caches (hereinafter “DNS cache servers”). DNS cache servers store domain names and mappings to the associated IP addresses for some of the more commonly-requested web pages. DNS queries are directed to DNS cache servers in the hope that a DNS cache server will be able to answer the query based on an IP address in its local cache. Only where an answer has not been cached in the DNS cache server handling a query is the DNS query forwarded to one or more authoritative DNS servers.
Whether the DNS answer (e.g., an IP address of the requested web page) is obtained from a DNS cache server or from an authoritative DNS server, the DNS answer is then returned to the client that made the DNS query allowing the client to connect to the web server hosting the desired web page.
A DNS answer can include one or more data records each with a time-to-live (TTL) value that indicates how long the data is valid (not-expired). For instance, where an authoritative DNS server wants to ensure that an IP address for a web server is updated frequently, the authoritative DNS server may set a lower TTL value. A DNS answer can be cached and used to answer subsequent DNS queries as long as the TTL has yet to expire. In other words, while the TTL is ticking down, the recursive DNS need not query the remote DNS server to answer the same DNS query. However, when a DNS answer's TTL expires, the recursive DNS server typically makes queries to authoritative DNS servers to obtain a fresh copy of the data to use in DNS answers.
Sometimes the recursive DNS server is temporarily unable to update a previously valid, but, expired DNS answer in its cache. This frequently occurs when network connectivity is interrupted, so the authoritative DNS server cannot be reached, the authoritative DNS server returns an empty answer, or the authoritative DNS server returns an error. If a client requests an answer during this period, then the recursive DNS server will present the client with an error or empty message. Traditionally, such responses were not major problems and a user could merely press a reset browser button or wait a short time for the domain to come back online.
However, changes to the Internet mean that such delays, even if momentary (e.g., 30 seconds), are less tolerable today. These changes include higher volumes, more stringent consumer expectations, and more frequently updated content (e.g., streaming content, dynamic advertising, and VOIP).
This problem is enhanced by the fact that Request for Comments (RFC) standards prevent the recursive DNS server from following up a failed query for a specified period of time (e.g., 5 minutes). If an authoritative DNS server is unresponsive for a minute, but the recursive DNS server cannot recheck for updated data for five minutes after a first unsuccessful query, then there are 4 minutes of unnecessary disconnect between the client and the desired website.